home *** CD-ROM | disk | FTP | other *** search
-
-
-
- iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd((((3333GGGG)))) iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd((((3333GGGG))))
-
-
-
- NNNNAAAAMMMMEEEE
- iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd - registers the screen background process
-
- CCCC SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCAAAATTTTIIIIOOOONNNN
- vvvvooooiiiidddd iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd(((())))
-
- PPPPAAAARRRRAAAAMMMMEEEETTTTEEEERRRRSSSS
- _n_o_n_e
-
- DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
- iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd registers a process that maintains the screen background.
- Call it before wwwwiiiinnnnooooppppeeeennnn. The process should redraw the screen background
- each time it receives a REDRAW event.
-
- There is only one background so only one iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd process can run
- at a time. Any existing iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd process is killed when a new one
- is started.
-
- Because the X Window System's inability to change the mode (called the
- _v_i_s_u_a_l in xspeak) of a window conflicts with the GL's freedom to change
- modes at any time, iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd processes cannot paint on the real
- background (called the _r_o_o_t _w_i_n_d_o_w in xspeak). Instead a new window is
- created with the correct visual. This window is kept at the bottom of the
- stack of windows just above the screen background. This iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd
- window works better when it is what in xspeak is called an _o_v_e_r_r_i_d_e-
- _r_e_d_i_r_e_c_t window. In simple terms this means the window is not managed by
- the window manager.
-
- A window that is managed is likely to be given borders by the window
- manager. Currently only _4_D_w_m(_1_X) and _m_w_m(_1_X) understand the request to
- turn off the borders. Also the window manager will post the usual window
- menu for a managed window. You cannot access the _r_o_o_t _m_e_n_u. A managed
- window is useful, however, when the iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd process is running in
- color map mode (see _c_m_o_d_e(_3_G)). The window manager is the only process
- that can install the GL color map according to its own color map
- management policies so that the window is displayed correctly at the
- expected times.
-
- Because of this dichotomy, there is an X resource that controls whether
- or not the iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd window is managed. The full resource class is
-
- _N_a_m_e.GL.GLBackground.Manage
-
- _N_a_m_e is the name of the window taken from the argument to winopen The
- resource can have the values _t_r_u_e or _f_a_l_s_e. The default is _f_a_l_s_e. In
- other words if the resource isn't specified the iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd window is
- not managed. We recommend using managed windows for _c_m_o_d_e(_3_g) processes
- and non-managed windows for _R_G_B_m_o_d_e(_3_g) processes. For example the
- following entries in the X resource database
-
-
-
-
-
-
- PPPPaaaaggggeeee 1111
-
-
-
-
-
-
- iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd((((3333GGGG)))) iiiimmmmaaaakkkkeeeebbbbaaaacccckkkkggggrrrroooouuuunnnndddd((((3333GGGG))))
-
-
-
- *GLBackground.Manage: false
- texback*GLBackground.Manage: true
-
- cause background windows to be unmanaged except for a background program
- called _t_e_x_b_a_c_k which is known to be a _c_m_o_d_e(_3_g) program.
-
- SSSSEEEEEEEE AAAALLLLSSSSOOOO
- winopen
-
- NNNNOOOOTTTTEEEE
- This routine is available only in immediate mode.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PPPPaaaaggggeeee 2222
-
-
-
-